各位戰士，歡迎回到前線。昨天我們成功用 Top Down 列表抓到了一個明顯的敵人，但那只是新兵等級的對手。在真實的戰場上，敵人（性能瓶頸）往往狡猾地隱藏在層層的函式呼叫之中，讓你很難從列表中直接看出誰才是主謀。

這時，我們需要一張更直觀的作戰地圖，而火焰圖 (Flame Chart) 就是為此而生的終極武器。

什麼是火焰圖？

Top Down 和 Bottom Up 列表是數據，而火焰圖是畫。它將時間內的函式呼叫堆疊轉換成一個極其直觀的視覺化圖表，看起來就像一團燃燒的火焰，因此得名。

在 CPU Profiler 的分析面板中，切換到 Flame Chart 標籤頁，你就能看到它。

這張圖包含了兩個核心維度的資訊：

• Y 軸 (垂直方向)：代表呼叫堆疊。最上方的函式是呼叫的起點，它下面的函式是它呼叫的，以此類推，越往下層，呼叫堆疊越深。
• X 軸 (水平方向)：代表時間。一個函式方塊的寬度，就代表了它運行的時間長度。方塊越寬，代表它耗時越長。

如何解讀這張作戰地圖？

解讀火焰圖就像一名指揮官俯瞰整個戰場，你需要掌握幾個關鍵技巧：

1. 尋找最寬的平台：你的第一眼，應該要去尋找圖中最寬的那些方塊。一個寬大的方塊意味著這個函式本身或其子函式佔用了大量的 CPU 時間，這就是我們的重點懷疑對象。

2. 自頂向下分析：從一個寬方塊開始，觀察它下方呼叫了哪些函式。如果它下方的某個子函式方塊幾乎和它一樣寬，那說明大部分時間都消耗在了這個子函式裡。如果它下方是多個窄方塊，那說明是這個函式自身（而非其子函式）消耗了大量時間。

3. 注意顏色區分：

   • 橘色/黃色：通常代表你自己的應用程式碼 (Java/Kotlin)。這是我們最關心的部分！
   • 藍色：通常代表 Android 系統 API 的程式碼 (e.g., android.*, java.*)。
   • 綠色：通常代表 C/C++ 的原生程式碼。

   當你看到一個寬大的橘色方塊時，就意味著你找到了可以直接動手優化的程式碼。

實戰演練：分析一個更複雜的場景

假設我們有一個函式，它在內部呼叫了另外兩個函式，其中一個非常耗時：

fun processUserData() {
    // 步驟一：從資料庫讀取資料 (相對較快)
    val users = readUsersFromDatabase() // 假設耗時 50ms

    // 步驟二：對每個使用者進行複雜的資料轉換 (非常耗時)
    val processedData = transformUserData(users) // 假設耗時 800ms

    // 步驟三：更新 UI
    updateUi(processedData)
}

// 這個函式是真正的元兇
private fun transformUserData(users: List<User>): List<Data> {
    // ... 極其複雜的迴圈和計算 ...
    Thread.sleep(800) // 模擬耗時
    return emptyList()
}

當你用 Profiler 記錄 processUserData 的執行過程後，你可能會在火焰圖中看到類似這樣的結構：

最頂層是一個很寬的 processUserData 方塊。

在它的正下方，你會看到兩個子方塊：一個很窄的 readUsersFromDatabase 和一個非常寬的 transformUserData。

這張圖一目了然地告訴你：processUserData 的總耗時，絕大部分元兇是 transformUserData！你甚至不需要去看 Top Down 列表中的數字，就能瞬間定位問題。這就是火焰圖的威力。

今日總結

今天我們解鎖了 CPU Profiler 中最強大的視覺化工具。現在，你應該能夠：

• 理解火焰圖的 X 軸（時間）和 Y 軸（呼叫堆疊）代表的意義。

• 透過尋找「最寬的平台」來快速定位性能瓶頸。

• 利用顏色來區分應用程式碼和系統程式碼。

Top Down 列表給我們精確的數字，而火焰圖給我們宏觀的視野。兩者結合，才能讓我們成為真正高效的性能偵探。

CPU 的偵查任務暫告一段落。明天，我們將轉移到另一個同樣重要的戰場——記憶體。準備好學習如何使用 Memory Profiler，揪出那些侵佔寶貴記憶體資源的「洩漏者」。

我們明天見！